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© System state controller for electronic image processing systems. 



© A system state controller (160) for an electronic reprographic system to balance system resources in 
accordance with demand when processing Jobs. A controller includes plural discrete job processing 
virtual machines (168, 174, 178, etc.) with each of the virtual machines having at least one service (170, 
176, 180, etc.) associated with it for implementing the virtual machine, each of the services having at 
least one of the system hardware and software components for carrying out the service. A scheduling 
means (210) sets priorities for carrying out the virtual machines to process job requests in an efficient 
manner. 
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The invention relates to electronic image and 
PDL (page description language) processing sys- 
tems, and more particularly, to a system state control- 
ler for efficiently controlling activities and resource 
usage within such systems. s 

In the past, copiers provided limited concurrent 
functions that were implemented by electro-mechani- 
cal components, the functions being primarily dedi- 
cated to one main task, i.e., copy a job, and with one 
main user. I.e., the operator. The top level control 10 
software controlled the sequential operation, 
gathered fault and state information from the func- 
tional components below it, determined the overall 
state and active faults of the system, and used this 
information to present operator messages or inhibit 15 
certain features. With the advent of electronic repro- 
graphics systems, multiple users such as operator net 
clients, etc are possible. Further, various configu- 
rations tailored to address specific markets and needs 
that provide unique sets of functions to the customer 20 
but built on a single common software package are 
possible. 

In the prior art, US-A-4,888,771 to Benignus et al 
discloses a diagnostic configuration management 
system for a data processing system used to decide 25 
which configuration of processor elements can be 
used based upon known faults. U S. Patent No. 
3,838,260 to Nelson discloses a microprogrammable 
control memory diagnostic system wherein fault 
detection is performed concurrently with normal data 30 
processing, while US-A-4,81 5,076 to Denney et al 
discloses a reconfiguration control which provides 
several different ways to recover from a single or mul- 
tiple component fault US-A-4,691 ,317 to Miazga et al 
discloses a feature de-select control system enabling 36 
features on a xerographic copier to be de-selected 
while enabling the copier to continue to operate with 
other features. And US-A-4,922,491 to Coale dis- 
closes an input/output service alert using a method of 
automatically analyzing exception states within com- 40 
puter peripheral subsystems. 

In contrast, the present invention provides a state 
controller for an electronic reprographic system for 
controlling system operations when processing 
requests in which the system has a plurality of 45 
hardware and software components providing dis- 
crete services for processing requests and maintain- 
ing operation of the system, and job programming 
means including a display screen for inputting 
requests, the controller being independent of other so 
parts of the system, comprising: a state holder for 
monitoring the current operating state of the system 
components; plural discrete job processing virtual 
machines with each of the virtual machines having at 
least one service associated with it for implementing 55 
the virtual machine; each of the services having at 
least one of the components for carrying out the ser- 
vice; and scheduling means for setting priorities for 



carrying out the transactions to process the requests 
in an efficient manner. 

A state controller for an electronic reprographic 
system in accordance with the Invention will now be 
described, by way of example, with reference to the 
accompanying drawings, in which:- 

Figure 1 is a view depicting an electronic system 

incorporating the System State Controller of the 

present invention; 

Figure 2 is a block diagram depicting the major 
elements of the system shown in Figure 1 ; 
Figure 3 is a plan view illustrating the principal 
mechanical components of the system shown in 
Figure 1; 

Figure 4 is a schematic view showing certain con- 
struction details of the document scanner of the 
system shown in Figure 1; 
Figures 5A, 5B, and 5C comprise a schematic 
block diagram showing the major parts of the con- 
trol section for the system shown in Figure 1; 
Figure 6 is a block diagram of the Operating Sys- 
tem, together with Printed Wiring Boards and 
shared line connections for the system shown in 
Figure 1; 

Figure 7 is a view depicting an exemplary job pro- 
gramming ticket and job scorecard displayed on 
the User Interface (Ul) touchscreen of the system 
shown in Figure 1 ; 

Figure 8 is a schematic block diagram depicting 
the System State Controller of the present inven- 
tion with Virtual Machine examples; 
Figure 9 is a schematic block diagram showing 
details of the System State Controller including 
virtual machines and service examples; and 
Figure 10 is a schematic block diagram showing 
, the relation between the System State Controller 
and other system components. 
As used herein, a "Request" is any set of instruc- 
tions or commands input by an operator, arriving via 
the network, or generated internally by the system. A 
Request is issued to: 

- initiate new processing on a job (e.g. scan & 
print the job, edit the stored job, etc. ) 

- generally control the system's operation (e.g. 
stop the printer & any related print processing, 
shut down all current processing in preparation 
for power off or switch to diagnostic mode, etc) 

- control previously initiated job processing (e.g. 
abort the job, suspend the job, resume a previ- 
ously suspended Job, etc.) 

Each Request which initiates new job processing 
is asking system 2 to perform some function which is 
divided into a series of "Virtual Machines" 156 (shown 
in Figure 8). A virtual machine is logically a single 
operation on a job while a set of virtual machines is a 
plurality of discretely controlled operations for proces- 
sing jobs. In actual implementation, each Virtual 
Machine 156 requires various system "Services" or 
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Service Pieces 158 to carry out its operation. Each 
Service Piece 158 provides a specific low level sys- 
tem function. The same Service Piece may be used 
by multiple transactions as part of a higher level logi- 
cal operation. In providing its specific function, each 
Service Piece uses basic system "Components* or 
physical resources such as hardware modules, 
software modules, or system resources (memory, 
disk, etc). The same Components may be used by 
multiple Service Pieces. 

Individual Virtual Machines are identified by a 
, Transactionld , \ Individual Service Pieces are iden- 
tified by a "Serviceld When a particular Service 
Piece 1 58 is working on behalf of a specific Virtual 
Machine 156, it identifies itself by a "ResManager ID" 
which consists of a Transaction^, Serviceld pair. 
Resource (Res) Manager defines resource mapping 
that provides resources to clients on demand 

Referring to Figures 1 and 2, there is shown an 
exemplary system 2 supporting the processing of 
Requests in accordance with the teachings of the pre- 
sent invention. As will appear, system 2 has a plurality 
of independent functions (such as scan, print, etc.) 
which operate asynchronously, with operation being 
implemented by a shared set of Service Pieces and 
components. The exemplary system 2 shown for pur- 
poses of explanation provides network, scan, make 
ready, and print functions with both remote and on- 
site inputs in the form of network 5 and scanner 6, con- 
troller 7, and printer 8. Inputs to scanner are images, 
whereas inputs from network 5 are PDL (page des- 
cription language) formats such as Interprets, Post- 
script, or HP PCL To enable system 2 to be tailored 
to the specific needs of different customers and pro- 
vide different functions to different customers, other 
configurations may be envisioned such as a stand 
alone printing system composed of scanner, control- 
ler, and printer 6, 7, 8 respectively, a network printer 
composed of network 5, controller 7, and printer 8 re- 
spectively, etc. 

In system 2, components such as memory are 
shared by different Service Pieces running concur- 
rently on behalf of various Virtual Machines which 
have been initiated in order to meet the current set of 
new job processing Requests. As a result, it is neces- 
sary, when these components become scarce or 
unavailable as, for example, due to a fault, overload, 
etc. to reprioritize the Virtual Machines. This may lead 
to shutdown of one or more Virtual Machines even 
though all the Service Pieces needed by that Virtual 
Machine are ready and able to perform. These same 
Service Pieces will continue to be available for Virtual 
Machines other than the Virtual Machine or Machines 
shut down. 

In order to provide a balance between the Virtual 
Machines, allow interaction in a controlled and effi- 
cient manner and provide priorization of response to 
Requests, the present invention is provided. 



Referring particularly to Figures 2-4, network 5 
comprises any suitable communication channel such 
as a telephone line for enabling data from one or more 
remote sources to be input to system 2 for processing. 

6 Scanner 6 incorporates a transparent platen 20 

on which the document 22 to be scanned is located. 
One or more linear arrays 24 are supported for recip- 
rocating scanning movement below platen 20. Lens 
27 and mirrors 28, 29, 30 cooperate to focus array 24 

10 on a line like segment of platen 20 and the document 
being scanned thereon. Array 24 provides image sig- 
nals or pixels representative of the image scanned 
which after suitable processing by processor 25, are 
output to controller 7. 

15 Processor 25 converts the analog image signals 

output by array 24 to digital and processes the image 
data from network 5 and scanner 6 as required to 
enable system 2 to store and handle the image data 
in the form required to carry out the job programmed. 

20 For image data input by scanner 6, processor 25 also 
provides enhancements and changes to the image 
signals such as filtering, thresholding, screening, 
cropping, reduction/enlarging, etc. Following any 
changes and adjustments in the job program, the 

25 document must be re-scanned. 

Documents 22 to be scanned may be located on 
platen 20 for scanning by automatic document hand- 
ler (ADF) 35 operable in either a Recirculating Docu- 
ment Handling (RDH) mode or a Semi-Automatic 

30 Document Handling (SADH) mode. A manual mode 
including a Book mode and a Computer Forms 
Feeder (CFF) mode are also provided, the latter to 
accommodate documents in the form of computer 
fanfold. For RDH mode operation, document handler 

35 35 has a document tray 37 in which documents 22 are 
arranged in stacks or batches. The documents 22 in 
tray 37 are advanced by vacuum feed belt 40 and 
document feed roils 41 and document feed belt 42 
onto platen 20 where the document is scanned by 

40 array 24. Following scanning, the document is 
removed from platen 20 by belt 42 and returned to tray 
37 by document feed roils 44. 

For operation in the SADH mode, a document 
entry slot 46 provides access to the document feed 

46 belt 42 between tray 37 and platen 20 through which 
individual documents may be inserted manually for 
transport to platen 20. Feed rolls 49 behind slot 46 
form a nip for engaging and feeding the document to 
feed belt 42 and onto platen 20. Following scanning, 

so the document Is removed from platen 20 and dis- 
charged into catch tray 48. 

For operation in the CFF mode, computer forms 
material is fed through slot 46 and advanced by feed 
rolls 49 to document feed belt 42 which in turn adv- 

55 ances a page of the fanfold material into position on 
platen 20. 

Referring to Figures 2 and 3, printer 8 comprises 
a laser type printer and for purposes of explanation is 

4 
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separated into a Raster Output Scanner (ROS) sec- 
tion 87, Print Module Section 95, Paper Supply sec- 
tion 107, and Finisher 120. ROS 95 has a laser 91 , the 
beam of which Is split into two imaging beams 94. 
Each beam 94 is modulated in accordance with the 
content of an image signal input by acousto-optic 
modulator 92 to provide dual imaging beams 94. 
Beams 94 are scanned across a moving photorecep- 
tor 98 of Print Module 95 by the mirrored facets of a 
rotating polygon 100 to expose two image lines on 
photoreceptor 98 with each scan and create the latent 
electrostatic images represented by the image signal 
input to modulator 92. Photoreceptor 98 is uniformly 
charged by corotrons 102 at a charging station prep- 
aratory to exposure by imaging beams 94. The latent 
electrostatic images are developed by developer 104 
and transferred at transfer station 106 to a print media 
108 delivered by Paper Supply section 107. Media 
108 may comprise any of a variety of sheet sizes, 
types, and colors. For transfer, the print media is 
brought forward in timed registration with the 
developed image on photoreceptor 98 from either a 
main paper tray 1 1 0 or from auxil iary paper trays 112, 
or 114. The developed image transferred to the print 
media 108 is permanently fixed or fused by fuser 116 
and the resulting prints discharged to either output 
tray 118, or to finisher 120. Finisher 120 includes a 
stitcher 1 22 for stitching or stapling the prints together 
to form books and a thermal binder 1 24 for adhesively 
binding the prints Into books. 

Referring to Figures 1 , 2 and 5 ? controller 7 is, for 
explanation purposes, divided into an image input 
controller 50, User Interface (Ul) 52, system controller 
54, main memory 56, image manipulation section 58, 
and image output controller 60. 

Image data input to controller 7 is compressed by 
image compressor/processor 51 of image input con- 
troller 50 on PWB 70-3. As the image data passes 
through compressor/processor 51, it is segmented 
into slices N scanlines wide, each slice having a slice 
pointer. The compressed image data together with 
slice pointers and any related image descriptors pro- 
viding image specific information (such as height and 
width of the document in pixels, the compression 
method used, pointers to the compressed image data, 
and pointers to the image slice pointers) are placed in 
an image file. The image files, which represent diffe- 
rent Requests, are temporarily stored in system mem- 
ory 61 which comprises a Random Access Memory or 
RAM pending transfer to main memory 56 where the 
data is held pending use. 

As best seen in Figure 1, Ul 52 includes a com- 
bined operator controller/CRT display consisting of an 
interactive touchscreen 62, keyboard 64, and mouse 
66. Ul 52 interfaces the operator with printing system 
2, enabling the operator to program Requests and 
other instructions, to obtain system operating infor- 
mation, instructions, programming information, diag- 



nostic Information, etc. Items displayed on touchsc- 
reen 62 such as fifes and icons are actuated by either 
touching the displayed item on screen 62 with a finger 
or by using mouse 66 to point cursor 67 to the item 

s selected and keying the mouse. 

Main memory 56 has plural hard disks 90-1 , 90-2, 
90-3 for storing machine Operating System software, 
machine operating data, and the scanned image data 
currently being processed. 

10 When the compressed image data in main mem- 
ory 56 requires further processing, or is required for 
display on touchscreen 62 of Ul 52, or is required by 
printer 8, the data is accessed an main memory 56. 
Where further processing other than that provided by 

15 processor 25 is required, the data is transferred to 
image manipulation section 58 on PWB 70-6 where 
the additional processing steps such as collation, 
make ready, decomposition, etc. are carried out. Fol- 
lowing processing, the data may be returned to main 

20 memory 56, sent to Ul 52 for display on touchscreen 
62, or sent to image output controller 60. 

Image data output to image output controller 60 
is decompressed and readied for printing by image 
generating processors 86 of PWBs 70-7, 70-8 (seen 

25 in Figure 5A). Following this, the data is output by dis- 
patch processors 88, 89 on PWB 70-9 to printer 8. 
Image data sent to printer 8 for printing is normally 
purged from memory 56 to make room for new image 
data, 

30 Referring particularly to Figures 5A-5C, control 7 
includes a plurality of Printed Wiring Boards (PWBs) 
70, PWBs 70 being coupled with one another and with 
System Memory 61 by a pair of memory buses 72, 74. 
Memory controller 76 couples System Memory 61 

35 with buses 72, 74. PWBs 70 include system pro- 
cessor PWB 70-1 having plural system processors 
78; low speed I/O processor PWB 70-2 having Ul 
communication controller 80 for transmitting data to 
and from Ul 52; PWBs 70-3, 70-4, 70-5 having disk 

40 drive controller/processors 82 for transmitting data to 
and from disks 90-1, 90-2, 90-3 respectively of main 
memory 56 (image compressor/processor 51 for com- 
pressing the image data is on PWB 70-3); image 
manipulation PWB 70-6 with image manipulation pro- 

45 cessors of image manipulation section 58; image gen- 
eration processor PWBs 70-7, 70-8 with image 
generation processors 86 for processing the image 
data for printing by printer 8; dispatch processor PWB 
70-9 having dispatch processors 88, 69 for controlling 

so transmission of data to and from printer 8; and boot 
control-arbitration-scheduler PWB 70-10. 

Referring particularly to Figure 6, system control 
signals are distributed via a plurality of printed wiring 
boards (PWBs). These include EDN core PWB 130, 

55 Marking Imaging core PWB 132, PaperHandling core 
PWB 134, and Finisher Binder core PWB 136 
together with various Input/Output (I/O) PWBs 138. A 
system bus 140 couples the core PWBs 130, 132, 
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134, 136 with each other and with controller 7 while 
local buses 142 serve to couple the I/O PWBs 138 
with each other and with their associated core PWB. 

On machine power up, the Operating System 
software Is loaded from memory 56 to EDN core PWB 
130 and from there to the remaining core PWBs 132, 
134, 136 via bus 140, each core PWB 130, 132, 134, 
136 having a boot ROM 147 for controlling download- 
ing of Operating System software to the PWB, fault 
detection, etc. Boot ROMs 147 also enable transmis- 
sion of Operating System software and control data to 
and from PWBs 130, 132, 134, 136 via bus 140 and 
control data to and from I/O PWBs 1 38 via local buses 
142. Additional ROM, RAM, and NVM memory types 
are resident at various locations within system 2. 

Referring to Figure 7, jobs are programmed in a 
Job Program mode in which there is displayed on 
touchscreen 62 a Job Ticket 150 and Job Scorecard 
1 52 for the job being programmed. Job Ticket 1 50 dis- 
play various job selections programmed while Job 
Scorecard 152 displays the basic instructions to the 
system for printing the job. 

Referring to Figures 8-10, image manipulation 
processor 58 includes a System State Controller 
(SSC) 160 which serves as a function executor for 
controlling and prioritizing operation of the various Vir- 
tual Machines in response to Job Processing 
Requests. SSC 160 receives Job Processing 
Requests from function queue 165 and converts the 
Request into a series of discrete Virtual Machines 1 56 
with the Service Pieces 158 needed to carry out the 
job programmed. 

SSC 1 60 includes a state holder 162 which main- 
tains a running log of the state of the various Virtual 
Machines and Service Pieces that comprise system 2. 
The operating state and fault/condition of the Service 
Pieces and their components are monitored by a suit- 
able state detector 161 and fault/condition detector 
163 which continuously feed back updated service 
and component condition data to SSC state holder 
162. SSC 160 also includes Long Term Scheduler 
(LTS) 164 which sets priorities for the Virtual 
Machines required when processing jobs. 

In the example shown In Figure 9, Virtual 
Machine, Service Piece and Job Processing Request 
mappings are as follows: 

. Capture Inter-Press (IP) 168 comprised of pre- 
parer service 170 and Image Conversion Ser- 
vice (ICS) 182 - enables input of PDL data to 
system 2 from network 5; 
. Scan-To-Disk 174 comprised of scan service 
176 - enables input of image data from scanner 
6; 

. Page Edit 176 comprised of post parse service 
180 and (ICS) 182 - enables a local operator to 
view and alter portions of a job; 
. Coalesce 184 comprised of ICS service 182, 
post parse service 160 and other services such 



as rotate 1 65 enables the preparation of a job for 
printing; 

. Background 186 enables housekeeping func- 
tions that go on anytime system 2 is up and run- 
5 ning; 

. Disk-To-Print 188 comprised of post parse ser- 
vice 160 and mark service 192 enables the trans- 
fer of electronic input data on disk to images on 
paper provided by printer 8. 
10 Other Virtual Machines and service combinations 
may be envisioned. 

Referring particularly to Figure 10, operator 
instructions or commands input via Ul 52 are accep- 
ted by dialog 194. The dialog is thereafter converted 
15 by Trillium Emulator (TEM) 196 into the internal lan- 
guage (i.e. Mesa) used by system 2. Commands and 
PDL data received via network 5 are converted by 
pre-parser service 170 to the internal format used by 
system 2. It is understood that image data input via 
20 scanner 6 does not require pre-parsing. Other data 
includes background data that is generated whenever 
system 2 is running, since certain background oper- 
ations take place to maintain the system in an operat- 
ing condition. 

25 A command processor 200 converts the com- 
mands into a set of job processor an SSC commands 
which are forwarded to job processor 202 and to SSC 
160. Command processor 200 also enables recovery 
of faulted objects (i.e., jobs) and provides a faulted job 

30 count ("faults") by queue for display by status handler 
208. 

Job processor 202 maintains a database of jobs 
in system 2 and function queues. Processor 202 also 
manages the data manipulation required for running 

35 jobs in the system and provides job state information 
("Job state") to command processor 200 processor 
202 provides SSC 160 with tasks (steps) that have 
passed all job requirements for a particular ser- 
vice,and passes an identifier (i.e., Res Manager ID) 

40 for tasks that are ready to be processed to SSC. Pro- 
cessor 202 also informs SSC when a high priority task 
for service is available thus managing task priorities. 
Processor 202 receives job processing results ("Job 
Results") from schedulers 210 and uses this data to 

45 build and checkpoint jobs. Processor 202 also 
receives service rates and data ("Service Rates & 
Data") from schedulers 210 to determine when a task 
should be made available, and job queue information 
("Job Queue") for input ("Queue data") to SSC 160 so 

so that the SSC can make intelligent resource tradeoffs. 
Schedulers 210 ("Step Executors") include mark 
scheduler 212, scan scheduler 214, ICS scheduler 
216, post-parse scheduler 218, and pre-parse 
scheduler 219 for scheduling tasks carried out by 

55 mark, scan, ICS, post parse, and pre-parse services 
192, 176, 182, 180, 170 respectively in accordance 
with commands from SSC 160. Schedulers 210 per- 
form processing of a task for the Service associated 
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with the task, checking parameters, updating task 
state, and adding pages to a job. Schedulers 210 
track their own faults, and provide means for SSC 1 60 
to control component usage (i.e., stop, abort, resume, 
power off, initialize, etc). Schedulers 21 0 also provide 5 
page, set, and job done data to SSC 160, implement 
interrupts at the page and set boundaries, and imple- 
ment resume. 

SSC 160 Is an example of a "Function Executor 4 '. 
SSC 1 60 understa nds what needs to be be done to or 10 
with portions of system 2 to accomplish a Request 
SSC 160 accepts service commands ("Service Com- 
mands") with task identifier (i.e., Res Manager ID) 
from job processor 202 and decides, based on current 
system operating data (i.e., fault, resource, state) tf a 15 
service for a Virtual Machine is ready to accept a com- 
mand. SSC 160 calls schedulers 210 to change state 
("change State") by executing commands. SSC 160 
also implements interrupts at the job level and 
resumes, and accepts higher priority tasks from job 20 
processor 202. SSC 160 receives data about state 
changes from different parts of the system to maintain 
a current view of the system state. SSC 160 also coor- 
dinates the interactions between multiple services, 
and provides service states, faults, and current job 25 
information to status handler 208 for display on 
touchscreen 62 of Ul 52. 

SSC 160 enables and tracks clearance and 
recovery from faults. The clearance can be an ack- 
nowledgement from the local operator via a selection 30 
on touchscreen 62 of Ul 52 and passed through TEM 
196 or a sensing from within the system that all 
actions have been taken to clear the fault SSC 160 
also handles system resource problems by changing 
resource component priorities using allocator 220. 35 
For this, LTS 1 64 of SSC 1 60 uses data from schedul- 
ers 210 ("Page, Set Job Done".) and queue data (i.e., 
run lengths, etc.) from job processor 202 to make 
intelligent resource tradeoffs, using commands to 
appropriate service schedulers 210 to suspend or 40 
shutdown when their resource components are 
needed elsewhere. 

When a job enters system 2, Command Pro- 
cessor 200 updates job Processor 202 with all the 
required job data. The job processor 202 informs SSC 45 
160 when the job requires a particular service and 
waits for the appropriate scheduler 210 to retrieve the 
job for its service. If the service completes its task with 
no faults, the scheduler 210 updates the job pro- 
cessor 202 and then advances the job to the next ser- so 
vice. If, however, the service has a fault while 
performing its task, the scheduler 210 will inform SSC 
1 60 which will provide the state, fault, and current job 
information to status handler 208 for display on 
touchscreen 62 of Ui 52. If the fault is clearable, the 85 
service will resume its task upon clearance and recov- 
ery of the fault 

During a job, when a service working on behalf of 



a Virtual Machine requires more memory than is cur- 
rently assigned to it by LTS 164, the service mes- 
sages LTS 164. LTS 164 endeavors to find the 
additional memory with the least impact on system 
operation as for example by shifting available memory 
within a Virtual Machine from services not currently 
required and allocating the memory to the service 
making the request Where the amount of memory 
obtained Is insufficient within the Virtual Machine, LTS 
1 64 shutdowns other Virtual Machines in accordance 
with a determined priority until the needed memory is 
obtained. In the example shown, Disk-To-Print Virtual 
Machine 188 has the highest priority, Page Edit 178 
second priority, etc. Other or different priorities may, 
however, be envisioned. 

Background Virtual Machine 186 which go on all 
the time are normally excluded from the pool of Virtual 
Machines from which LTS 164 can obtain memory. 

SSC 160 also accepts Requests from the user or 
from within the system 2 that are not related to initiat- 
ing Job Processing. These Requests either modify 
the system's 2 operation or modify a job's processing 
that was previously initiated. In the former case, for 
example, the operator can request to power off sys- 
tem 2. If system 2 is processing jobs, SSC 160 will 
either abort all services running jobs or allow the ser- 
vices to complete the current jobs but prevent new 
jobs from starting. This decision is made by the 
operator. Once system 2 is quiesced, SSC 160 will 
initiate the power off. In the latter case, for example, 
the operator can request printer 8 to suspend and wait 
for further commands. SSC 160 will log the source of 
the request and command the service to suspend. 
When the operator provides its next request (i.e. abort 
or resume), SSC 160 will check the states for that ser- 
vice and Virtual Machine and will initiate the request 
If the states permit it 

With multiple sources for state changing 
Requests, SSC 160 could receive conflicting 
Request. To prevent system 2 from processing 
Requests in an illogical order, SSC 160 logs the origin 
of each Request and understands what is needed bef- 
ore resuming each service. For exemple, the marie 
service 192 can run out of data to print and inform 
SSC 160 of the problem. SSC 160 notes the problem 
and waits for Job Processor 202 to inform SSC 160 
that enough data has accumulated for the mark ser- 
vice 192 to resume. At the same time mark service 
192 suspends itself, the operator can request printer 
8 to stop. SSC 160 will also log the Request from the 
operator. SSC 160 will not resume mark service 192 
until both Job Processor 202 and the operator have 
provided their approval for resumption. 

Where LTS 164 senses that the performance of 
system 2 is degraded (i.e., at reduced speed) due to 
concurrency, the SSC may respond by temporarily 
shutting down some Virtual Machines in favor of 
others to allow an expedient completion of certain 
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Requests. 

While the invention has been described with 
reference to the structure disclosed, it is not confined 
to the details set forth , but is intended to cover such 
modifications or changes as may come within the 
scope of the following claims. 



Claims 

1. A state controller (160) for an electronic repro- 
graphic system for controlling system operations 
when processing requests in which said system 
has a plurality of hardware and software compo- 
nents providing discrete services for processing 
requests and maintaining operation of said sys- 
tem, and job programming means including a dis- 
play screen for Inputting requests, said controller 
being independent of other parts of said system, 
comprising: 

a) a state holder (162) for monitoring the cur- 
rent operating state of said system compo- 
nents; 

b) plural discrete job processing virtual 
machines (168, 174, 178, etc.) with each of 
said virtual machines having at least one ser- 
vice ( 170, 176, 180, etc.) associated with it for 
implementing the virtual machine; 

c) each of said services having at least one of 
said components for carrying out the service; 
and 

d) scheduling means (210) for setting priori- 
ties for carrying out said virtual machines to 
process said requests in an efficient manner. 

2. The state controller according to claim 1 including 
job processing means (202) adapted on program- 
ming a request to separate said request Into a mix 
of virtual machine selections for input to said state 
controller. 
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The state controller according to claim 5 in which 
said second scheduling means provides on-going 
job data to said job processor for use by said job 
processor in making said virtual machine selec- 
tions. 

The state controller according to claim 6 in which 
said job processing means provides job state 
information to said command processing means 
for display on said screen. 

The state controller according to claim 7 in which 
said job state information includes fault data; 

said command processing means display- 
ing said faults on said screen. 

The state controller according to claim 8 in which 
said scheduling means provides change of state 
commands to said second scheduling means in 
response to said service commands and said job 
queue information. 



3. The state controller according to claim 2 in which 
said job processing means (202) provides a task 
identifier with each of said virtual machine selec- 
tions. 



45 



The state controller according to claim 3 including 
command processing means (200) for converting 
job commands input to said system into requests 
for input to said job processing means for use in 
providing said virtual machine selections. 
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5. The state controller according to claim 4 including 
second scheduling means for at least one of said 
services for maintaining a queue of current Jobs 
using said service for input to said job processing 
means. 



55 
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